home *** CD-ROM | disk | FTP | other *** search
- Network Working Group Patrik Faltstrom
- Internet Draft: draft-faltstrom-macmime2-00 Dave Crocker
- Expiration 4/94 Erik E. Fair
- October 15, 1993
-
- MIME Content Type for BinHex encoded files
-
-
-
- 1. Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents at any timne. It is not appropriate to use
- Internet Drafts as reference material or to cite them other than as
- a "working draft" or "work in progress". Please check the
- 1idabstracts.txt listing contained in the internet-drafts Shadow
- Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
- ftp.nisc.sri.com, or munnari.oz.au to learn the current status of
- any Internet Draft.
-
- This specification is intended as an Informational document for
- transmission of files with the use of Macintosh specific encoding
- using BinHex4.0. For maximal interoperability, it is recommended
- that MIME-based application/applefile be used instead.
-
-
- 2. Abstract
-
- This memo describes the format to use when sending BinHex4.0 files
- via MIME [BORE93]. The format is compatible with existing
- mechanisms for distributing Macintosh files. Only when available
- software and/or user practice dictates, should this method be
- employed. It is recommended to use application/applefile for
- maximum interoperability.
-
-
- 3. Introduction
-
- Files on the Macintosh consists of two parts, called forks:
-
- DATA FORK: The actual data included in the file. The Data
- fork is typically the only meaningful part of a
- Macintosh file on a non-Macintosh computer system.
- For example, if a Macintosh user wants to send a
- file of data to a user on an IBM-PC, she would only
- send the Data fork.
-
- RESOURCE FORK: Contains a collection of arbitrary attribute/value
- pairs, including program segments, icon bitmaps,
- and parametric values.
-
-
- Faltstrom, Crocker, Fair [Page 1]
-
- Internet Draft Content Type for BinHex files October 15, 1993
-
- Additional information regarding Macintosh files is stored by the
- Finder has in a hidden file, called the "Desktop Database".
-
- Because of the complications in storing different parts of a
- Macintosh file in a non-Macintosh filesystem that only handles
- consecutive data in one part, it is common to convert the Macintosh
- file into some other format before transferring it over the network.
-
- AppleDouble file format [APPL90], encoded in MIME as
- multipart/appledouble and application/applefile is the preferred
- format for a Macintosh file that is to be included in an Internet
- mail message, because it provides recipients with Macintosh
- computers the entire document, including Icons and other Macintosh
- specific information, while other users easily can extract the Data
- fork (the actual data).
-
- However, this specification provides for use of the currently
- popular BinHex4.0 encoding schemes, as a convinience to the
- installed base of users.
-
-
- 4. MIME format for BinHex4.0
-
- MIME-base Apple information is specified by:
-
- MIME type-name: APPLICATION
- MIME subtype name: MAC-BINHEX40
- Required parameters: none
- Optional parameters: NAME, which must only consist of
- seven-bit US-ASCII characters excluding
- SPACE, CTLS, and "tspecials" as defined
- in RFC-1521 [BORE93].
- Encoding considerations: none
- Security considerations: See separate section in the document
- Published specification: Appendix A
- Rationale: Permits MIME-based transmission of data
- with Apple Macintosh file system specific
- information using a currently popular,
- though platform specific, format.
-
-
- 4a. Detail specific to MIME-based usage
-
- Macintosh documents do not always need to be sent in a special
- format. Those documents with well-known MIME types and
- non-existent or trivial resource forks can be sent as regular
- MIME body parts, without use of AppleSingle, AppleDouble or
- BinHex4.0.
-
- Documents which lack a data fork should always be sent as
- application/applefile.
-
-
- Faltstrom, Crocker, Fair [Page 2]
-
- Internet Draft Content Type for BinHex files October 15, 1993
-
- All other documents should normally sent as
- multipart/appledouble. This includes documents with non-trivial
- resource forks, and documents without corresponding well-known
- MIME types.
-
- It may be valuable in some cases to allow the user to choose one
- format over another, either because he disagrees with the
- implementor's definition of "trivial" resource forks, or for
- reasons of his own.
-
- Only when available software and/or user practice dictates,
- should application/mac-binhex40 be employed.
-
-
- 5. BinHex
-
- BinHex 4.0 is a propular means of encoding Macintosh files for
- archiving on non-Macintosh file systems and for transmission via
- Internet mail. (See Appendix A for a brief description of the
- BinHex 4.0 format.)
-
- The content-type application/mac-binhex40 indicates that the body of
- the mail is a BinHex4.0 file. Even though the BinHex encoding
- consists of characters which are not the same as those used in
- Base64 (those regarded as safe according to RFC-1521 [BORE93]) a
- transportation encoding should not be done.
-
- Even though a BinHex file includes the original Macintosh filename,
- it is recommended that a name parameter be included on the
- Content-Type header to give the recipient a hint as to what file is
- attached. The value of the name parameter must consist of seven-bit
- US-ASCII characters excluding SPACE, CTLS, and "tspecials" as
- defined in RFC- 1521 [BORE93].
-
-
- 5a. BinHex example
-
- Content-Type: application/mac-binhex40; name="car.hqx"
-
- [The BinHex4.0 file goes here]
-
-
- 6. References
-
- APPL90 AppleSingle/AppleDouble Formats for Foreign Files
- Developer's Note, Apple Computer, Inc., 1990
-
- BORE93 Borenstein N., and N. Freed, MIME (Multipurpose Internet
- Mail Extensions): Mechanisms for Specifying and Describing
- the Format of Internet Message Bodies, RFC 1521, Bellcore,
- Innosoft, September 1993.
-
-
-
- Faltstrom, Crocker, Fair [Page 3]
-
- Internet Draft Content Type for BinHex files October 15, 1993
-
- 7. Security Considerations
-
- To the extent that application/mac-binhex40 facilitates the
- transmission of operating-system sensitive data, it may open a door
- for easier relaxation of security rules than is intended either by
- the sender of the administrator of the sender's system.
-
-
- 8. Acknowledgements
-
- Thanks to all of the people on the ietf-822 list who have provided
- much meaningful input for this document. Some of them must though
- be remembered by name, because they have almost crushed my mailbox
- the last weeks with a very nice and interesting debate:
-
- Johan Berglund, Steve Dorner, David Gelhar, David Herron,
- Raymond Lau, Jamey Maze, John B. Melby, Jan Michael Rynning,
- Rens Troost, Peter Svanberg
-
-
- 9. Authors Addresses
- Patrik Faltstrom
- Department of Numerical Analysis and Computing Science
- Royal Institute of Technology
- S-100 44 Stockholm
- Sweden
-
- Email: paf@nada.kth.se
-
- Dave Crocker
- 675 Spruce. Dr.
- Sunnyvale, CA 94086
- USA
-
- Email: dcrocker@mordor.stanford.edu
-
- Erik E. Fair
- Engineering Computer Operations
- Apple Computer Inc.
-
- Email: fair@apple.com
-
-
- Appendix A. The BinHex format
-
- Here is a description of the Hqx7 (7 bit format as implemented in
- BinHex 4.0) formats for Macintosh Application and File transfers.
-
- The main features of the format are:
-
-
-
-
- Faltstrom, Crocker, Fair [Page 4]
-
- Internet Draft Content Type for BinHex files October 15, 1993
-
-
- 1) Error checking even using ASCII download
- 2) Compression of repetitive characters
- 3) 7 bit encoding for ASCII download
-
- The format is processed at three different levels:
-
- 1) 8 bit encoding of the file:
-
-
- Byte: Length of FileName (1->63)
- Bytes: FileName ("Length" bytes)
- Byte: Version
- Long: Type
- Long: Creator
- Word: Flags (And $F800)
- Long: Length of Data Fork
- Long: Length of Resource Fork
- Word: CRC
- Bytes: Data Fork ("Data Length" bytes)
- Word: CRC
- Bytes: Resource Fork ("Rsrc Length" bytes)
- Word: CRC
-
-
- 2) Compression of repetitive characters.
-
- ($90 is the marker, encoding is made for 3->255 characters)
-
- 00 11 22 33 44 55 66 77 -> 00 11 22 33 44 55 66 77
- 11 22 22 22 22 22 22 33 -> 11 22 90 06 33
- 11 22 90 33 44 -> 11 22 90 00 33 44
-
- The whole file is considered as a stream of bits. This stream will
- be divided in blocks of 6 bits and then converted to one of 64
- characters contained in a table. The characters in this table have
- been chosen for maximum noise protection. The format will start
- with a ":" (first character on a line) and end with a ":".
- There will be a maximum of 64 characters on a line. It must be
- preceded, by this comment, starting in column 1 (it does not start
- in column 1 in this document):
-
- (This file must be converted with BinHex 4.0)
-
- Any text before this comment is to be ignored.
-
- The characters used is:
-
- !"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
-
-
- Faltstrom, Crocker, Fair [Page 5]
-